Skip to content

[IRGenSIL] resolve objc_direct methods to precondition thunk if the flag is enabled#89234

Draft
DataCorrupted wants to merge 1 commit into
swiftlang:nextfrom
DataCorrupted:FixObjCDispatch
Draft

[IRGenSIL] resolve objc_direct methods to precondition thunk if the flag is enabled#89234
DataCorrupted wants to merge 1 commit into
swiftlang:nextfrom
DataCorrupted:FixObjCDispatch

Conversation

@DataCorrupted
Copy link
Copy Markdown
Contributor

@DataCorrupted DataCorrupted commented May 18, 2026

Swift has no notion of the ObjC flag -fobjc-direct-precondition-thunk we introduced in llvm/llvm-project#170618. This means when calling objc_direct methods from swift, it will dispatch to the true implementation -[Class method]D without the precondition check. This is incorrect.

In this PR we patch that up. When -fobjc-direct-precondition-thunk is enabled (queried from clang importer getClangCGM().getCodeGenOpts()), we lower FunctionRefInst by asking clang::CodeGen::getObjCDirectMethodCallee which function (thunk or true impl) would be the best callee.

A test is added to validate that we call correct thunk methods instead of true impl now.

An alternative approach is to do this query during irgen::getObjCDirectMethodCallee, a later time when we have lost access to the original ObjCMethodDecl unless we add it to FunctionPointer - a change I believe breaks the LLVM-level only abstraction, and would be too disruptive. Would open to comments if that sounds like a better idea.

@DataCorrupted
Copy link
Copy Markdown
Contributor Author

Targeting next branch as suggested by John, since llvm/llvm-project#170618 has been included in llvm next

@DataCorrupted
Copy link
Copy Markdown
Contributor Author

@swift-ci Please test

@DataCorrupted DataCorrupted changed the title [IRGenSIL] resolve objc_direct methods to tthunk if PreconditionThunk is enabled [IRGenSIL] resolve objc_direct methods to precondition thunk if the flag is enabled May 19, 2026
@DataCorrupted
Copy link
Copy Markdown
Contributor Author

@rjmccall The CI is using outdated toolchain and complaining "Libc++ only supports AppleClang 26.4 and later", and my local build would also fail because swift next branch is using APIs that's been updated in LLVM's next branch:

Swift file Old API LLVM commit New API
include/swift/AST/ASTNode.h#L94 PunnedPointer::getFromOpaqueValue(ptr) 46620f84b326 — PointerUnion refactored to PunnedPointer reinterpret_cast<intptr_t>(ptr)
include/swift/SILOptimizer/OptimizerBridgingImpl.h#L95 DomTreeNodeBase::getNumChildren() 284ef1b4acff — DomTree children stored as linked list std::distance(node->begin(), node->end())
include/swift/SILOptimizer/OptimizerBridgingImpl.h#L99 DomTreeNodeBase::begin()[index] same as above *std::next(node->begin(), index)
include/swift/SIL/PostOrder.h#L34 po_begin(F) / po_end(F) 691a130e0f14 — PostOrderIterator refactored post_order(F)
lib/SIL/IR/SILPrinter.cpp#L938 po_begin(F) / po_end(F) same as above post_order(F)

It's my first time sending PR to next branch, do you have suggestions on how to move forward here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant